Managing multiple network security devices from a manager device

ABSTRACT

The present invention is directed to a facility for using a security policy manager device to remotely manage multiple network security devices (NSDs). The manager device can also use one or more intermediate supervisor devices to assist in the management. Security for the communication of information between various devices can be provided in a variety of ways. The system allows the manager device to create a consistent security policy for the multiple NSDs by distributing a copy of a security policy template to each of the NSDs and by then configuring each copy of the template with NSD-specific information. For example, the manager device can distribute the template to multiple NSDs by sending a single copy of the template to a supervisor device associated with the NSDs and by then having the supervisor device update each of the NSDs with a copy of the template. Other information useful for implementing security policies can also be distributed to the NSDs in a similar manner. The system also allows a manager device to retrieve, analyze and display all of the network security information gathered by the various NSDs while implementing security policies. Each NSD can forward its network security information to a supervisor device currently associated with the NSD, and the manager device can retrieve network security information of interest from the one or more supervisor devices which store portions of the information and then aggregate the retrieved information in an appropriate manner.

CROSS-REFERENCE TO RELATED APPLICATION

[0001] This is a continuation of and claims priority to U.S. patentapplication Ser. No. 09/307,332, filed on May 6, 1999, and which ishereby incorporated herein by reference.

TECHNICAL FIELD

[0002] The present invention relates generally to communicatinginformation between computers, and more particularly to using a managerdevice to remotely manage multiple network security devices.

BACKGROUND OF THE INVENTION

[0003] As computer systems and other network devices (e.g., printers,modems, and scanners) have become increasingly interconnected, it isincreasingly important to protect sensitive information (e.g.,confidential business data, access information such as passwords, or anytype of data stored on certain devices) stored on one network devicefrom unauthorized retrieval by other network devices. The prevalence ofthe Internet and the growth of the World Wide Web have only exacerbatedthis issue.

[0004] One way to address this issue involves the use of networksecurity devices (“NSDs”) which attempt to control the spread ofsensitive information so that only authorized users or devices canretrieve such information. Some types of NSDs, such as firewalls andsecurity appliances, have a group of one or more trusted network devices(or networks consisting of trusted network devices) which the NSDattempts to protect from unauthorized external access. These NSDsmonitor network information passing between external network devices andthe devices in their group of trusted or internal devices. In addition,these NSDs typically implement a specified security policy by preventingthe passage of unauthorized network information between the external andthe trusted devices.

[0005] Those skilled in the art will appreciate that network informationcan be transmitted in a variety of formats. For example, networkinformation is often transmitted as a series of individual packets ofinformation, such as TCP/IP (Transfer Control Protocol/InternetProtocol) packets. While such packets will typically include the networkaddress (e.g., IP address) of the device to receive the information,other data about the network information (e.g., the specific type ofinformation being requested or sent) may be difficult to ascertain.

[0006] While a properly configured NSD can protect information stored onor accessible from trusted devices, it can be difficult to configureNSDs so that they correctly implement the desired security policies. Onesource of difficulty in configuring NSDs arises from the large number oftypes of network information which may be encountered. For example,there are a large number of network services and protocols whichexternal devices may attempt to provide to trusted devices or accessfrom trusted devices.

[0007] Such network services and protocols include, but are not limitedto, Archie, auth (ident), DCE-RPC (Distributed Computing EnvironmentRemote Procedure Call), DHCP (Dynamic Host Configuration Protocol)Client and Server, DNS (Domain Name Service), finger, FTP (File TransferProtocol), gopher, H.323, HTTP (HyperText Transfer Protocol),Filtered-HTTP, Proxied-HTTP, ICMP (Internet Control Message Protocol),NNTP (Network News Transfer Protocol), NTP (Network Time Protocol),ping, POP (Post Office Protocol) 2 and 3, RealNetworks, rlogin, rsh(Remote SHell), SMB (Simple Block Messaging), SMTP (Simple Mail TransferProtocol), SNMP (Simple Network Management Protocol), syslog, ssh(Secure SHell), StreamWorks, TCP/IP, telnet, Time, traceroute, UDP (UserDatagram Protocol), VDOLive, WAIS (Wide Area Information Services),whois, and other device-specific services. Those skilled in the art willappreciate the uses and details of these services and protocols,including the device ports typically used with the services andprotocols and the specified format for such information (e.g., theTCP/IP packet definition).

[0008] Another source of difficulty in configuring NSDs arises from thevariety of ways to handle network information of different types. Forexample, for each type of service or protocol, a NSD may wish to takedifferent actions for (e.g., allow passage of, deny passage of, orotherwise manipulate) the corresponding network information of thatservice or protocol. The decision to take these different actions canalso be based on additional factors such as the direction of informationflow (i.e., whether the network information is passing from a trusteddevice or to a trusted device) or on the basis of the sender or theintended recipient of the information (e.g., whether the networkinformation is passing from or to specific network devices or is passingfrom or to any network device of a specified class, such as any externaldevice).

[0009] The types of actions to be taken for the monitored networkinformation (based on the various factors such as the services andprotocols being used, the direction of the information flow, and theclasses of devices of the sender and the intended recipient) provide aninitial incomplete security policy. Various device-specific informationis necessary to configure a particular NSD with a specific securitypolicy that can be implemented by the device. The device-specificinformation which must typically be specified to create a specificsecurity policy includes, for example, the network address of the NSDand the network addresses of some or all of the trusted devices. If aparticular network service is to be provided to external devices by atrusted device, such as FTP access, information about the trusted FTPserver must also be available to the NSD.

[0010] A user such as a system administrator typically defines thespecific security policy for a NSD by determining the services andprotocols of interest and then configuring the NSD to protect thetrusted devices as appropriate. However, configuring an NSD can betime-consuming, and any mistakes in the configuration (e.g., failure todefine how a particular service should be handled, or allowing defaultbehaviors to allow passage of network information) can compromise theability of the NSD to protect sensitive information. Thus, the need forsystem administrators to configure each NSD can cause various problems.

[0011] When it is necessary to configure large numbers of NSDs, suchproblems are only exacerbated. If the security policies across some orall of the NSDs should be consistent (e.g., multiple devices in use by asingle company), the likelihood of mistakes increases. If the systemadministrator merely copies the specific security policy from one NSD toanother, mistakes may occur in re-specifying the various NSD-specificconfiguration information. Alternately, if the system administratorattempts to re-create the general security policy independently on eachNSD, various mistakes may occur such as neglecting to configure a typeof service or incorrectly configuring the actions for such a type.

[0012] In addition to implementing security policies which may restrictthe passage of some network information, NSDs typically gather networksecurity information about events of interest, including encounteringtypes of network information that is encountered as well as variousactions taken by the NSD. The network security information can bedisplayed to users such as system administrators so that they can verifythat the security policy is correctly implemented, produce reports aboutthe types and quantities of network information that is allowed to passand that is blocked from passage, and identify when external activitiesof concern (e.g., a hacker attack on the NSD) are occurring. NSDstypically maintain a local storage, often referred to as a log, of thesecurity information that they gather.

[0013] Some NSDs include computer software components executing ongeneral-purpose or dedicated computer hardware. For such an NSD, theexecuting software components assist in implementing the specificsecurity policies defined for the NSD. Use of software components allowsthe operation of the NSD to be upgraded in an efficient manner byreplacing some or all of the existing software components with newsoftware components. Such new software is typically distributed viaphysical media such as CDs or optical disks, and is loaded onto the NSDby an individual such as a system administrator.

SUMMARY OF THE INVENTION

[0014] Some embodiments of the present invention provide a facility forusing a security policy manager device to remotely manage multiplenetwork security devices (NSDs). In some embodiments, the manager deviceuses one or more intermediate supervisor devices to assist in themanagement. Security for the communications between the manager device,supervisor devices, and NSDs can be provided in a variety of ways.

[0015] The facility allows the manager device to create a consistentsecurity policy for the multiple NSDs by distributing a copy of asecurity policy template to each of the NSDs and by then configuringeach copy of the template with NSD-specific information. For example,the manager device can distribute the template to multiple NSDs bysending a single copy of the template to a supervisor device associatedwith the NSDs and by then having the supervisor device update each ofthe NSDs with a copy of the template. Other information useful forimplementing security policies for the NSDs, such as software componentsto be executed by the NSDs, can also be distributed by the managerdevice to the NSDs in a similar manner.

[0016] The facility also allows a manager device to retrieve, analyzeand display the network security information gathered by the variousNSDs while implementing security policies. Each NSD can forward itsnetwork security information to a supervisor device currently associatedwith the NSD, and can switch supervisor devices if the currentsupervisor device becomes unavailable. When the manager device desiresthe network security information for an NSD, the manager device contactsthe one or more supervisor devices which store portions of the networksecurity information of interest, retrieves the various portions of thenetwork security information, and then aggregates the retrievedinformation in an appropriate manner.

BRIEF DESCRIPTION OF THE DRAWINGS

[0017]FIG. 1 is a block diagram illustrating an embodiment of theNetwork Security Device Management (NSDM) system of the presentinvention.

[0018]FIG. 2 is a block diagram illustrating the flow of networksecurity information from a network security device (NSD) to the managerdevice.

[0019]FIGS. 3A-3H are examples of security policy templates.

[0020]FIGS. 4A-4H are an example of network security informationgenerated by implementing a specific security policy.

[0021]FIGS. 5A-5D are examples of a manager device's hierarchical viewof multiple supervisor devices and NSDs and of correspondingconfiguration and network information.

[0022]FIG. 6 is an example of one or more NSD software components whichcan be distributed by a manager device.

[0023]FIG. 7 is an exemplary flow diagram of an embodiment of theNetwork Security Device routine.

[0024]FIG. 8 is an exemplary flow diagram of an embodiment of the FilterNetwork Packets subroutine.

[0025]FIG. 9 is an exemplary flow diagram of an embodiment of theGenerate Network Security Information subroutine.

[0026]FIG. 10 is an exemplary flow diagram of an embodiment of theRespond To Management Message subroutine.

[0027]FIG. 11 is an exemplary flow diagram of an embodiment of theSupervisor Device routine.

[0028]FIG. 12 is an exemplary flow diagram of an embodiment of theProcess NSD Message subroutine.

[0029]FIG. 13 is an exemplary flow diagram of an embodiment of theProcess Manager Or Supervisor Device Message subroutine.

[0030]FIGS. 14A and 14B are exemplary flow diagrams of an embodiment ofthe Manager Device routine.

DETAILED DESCRIPTION OF THE INVENTION

[0031] An embodiment of the present invention provides a method andsystem for using a manager device to remotely manage multiple networksecurity devices. In particular, the Network Security Device Management(NSDM) system allows a security policy manager device to create aconsistent security policy for multiple network security devices (NSDs)by distributing a copy of a security policy template to each of the NSDsand by then configuring each copy of the template with NSD-specificinformation. Other information useful for implementing security policiesfor the NSDs, such as software components to be executed by the NSDs orlists of devices from whom information is to be blocked, can also bedistributed by the manager device to the NSDs in a similar manner. TheNSDM system also allows a manager device to retrieve, analyze anddisplay the network security information gathered by the various NSDswhile implementing security policies. In some embodiments, the managerdevice uses one or more intermediate supervisor devices to assist inmanaging the multiple NSDs.

[0032] Security policy templates can be defined by a user of the managerdevice and then used to implement consistent network security policiesacross multiple NSDs while reducing the risk of configuration error.Each template defines default network information filtering rules forvarious common services and protocols, and uses defined aliases torepresent various specific devices of interest for a particular NSD.Security policy templates are discussed in greater detail below, as wellas in the co-pending U.S. Patent Application entitled “GENERALIZEDNETWORK SECURITY POLICY TEMPLATES FOR IMPLEMENTING SIMILAR NETWORKSECURITY POLICIES ACROSS MULTIPLE NETWORKS,” filed May 6, 1999,incorporated herein by reference.

[0033] In order to remotely manage multiple NSDs, a manager device canuse one or more intermediate supervisor devices. For example, after asecurity policy template is defined, the manager device can distributethe template to multiple NSDs by sending a single copy of the templateto a supervisor device associated with the NSDs and by then having thesupervisor device update each of the NSDs with a copy of the template.Each of the NSD template copies can then be configured with NSD-specificinformation from one or more of a variety of sources, such as by themanager device, by a local user such as a system administrator, orautomatically such as with DNS information. In particular, aliases inthe template copy on a particular NSD can be replaced with informationabout the specific corresponding devices that are protected by the NSD,and NSD-specific access information can also be specified. For example,an alias for an HTTP server can be replaced with the specific networkaddress and name of the actual HTTP server.

[0034] Other information useful for implementing security policies forthe NSDs, such as software components to be executed by the NSDs, listsof devices to be blocked (i.e., to block information flowing from and/orto the device), or updates to existing templates in use, can also bedistributed by the manager device to the NSDs in a similar manner viathe supervisor devices. Such information can also be configured withNSD-specific information if necessary in the manner described above.Those skilled in the art will appreciate that configuration of an NSDcan occur not only when the NSD is initially installed, but also atlater times. In addition to providing information to the NSDs, themanager device can also provide various types of information to thesupervisor devices (e.g., software updates for software executing on thesupervisor devices).

[0035] One or more intermediate supervisor devices can also assist themanager device in retrieving, analyzing and displaying the networksecurity information gathered by the various NSDs. As each NSD executesand implements its specific security policy, the NSD gathers networksecurity information about its activities and about the networkinformation that is monitored. Each NSD forwards its network securityinformation to a host supervisor device currently associated with theNSD so that the supervisor device can host the network securityinformation by storing and/or processing it. If the supervisor devicecurrently associated with an NSD becomes unavailable, the NSD insteadforwards its network security information to one or more alternate hostsupervisor devices. In this manner, even if one supervisor devicebecomes unavailable, the network security information for the NSDs thatwere associated with the supervisor device is not lost. When the managerdevice wants to retrieve the network security information for an NSD,the manager device contacts the one or more supervisor devices whichstore portions of the network security information of interest,retrieves the various portions of the network security information, andthen aggregates the retrieved information in an appropriate manner.

[0036] In some embodiments, the manager device and supervisor devicesare external devices. Security for the communications between themanager device, supervisor devices, and NSDs can be provided in avariety of ways. For example, any of the information transmitted betweenthe NSDs and the supervisor devices and between the supervisor devicesand the manager device can be protected from unauthorized access byencrypting the information (e.g., using Data Encryption Standard (DES)in Cipher Block Chaining (CBC) mode). In addition, various schemes canbe used to ensure that NSDs and supervisor devices provide informationonly to authorized devices or users, such as by using passwords, hashingpasswords to produce keys, challenge/response, shared secrets, digitalIDs, or a list of devices defined as being authorized to request and/orreceive information. Part of the NSD-specific configuration of each NSDcan include associating one or more supervisor devices authorized tocommunicate with the NSD, as well as providing specific informationabout how the communication is to occur. User authentication can beperformed in a variety of ways, such as by using WINDOWS NT™ DomainUsers and Groups RADIUS user authentication, or CRYPTOcard.

[0037] Referring now to FIG. 1, an embodiment of the Network SecurityDevice Management (NSDM) system 100 includes a security policy managerdevice 110 able to communicate with multiple supervisor devices 120 and160, also referred to as host devices or event processors. Eachsupervisor device is associated with multiple NSDs, with supervisordevice 120 associated with NSDs 130 through 140 and with supervisordevice 160 associated with NSDs 161 through 162. Each NSD protects oneor more trusted devices from external devices, such as NSDs 130 and 140protecting devices (not shown) in internal networks 135 and 145respectively from devices (not shown) in external network 190. For thesake of brevity, supervisor device 160 and NSDs 161 through 162 are notdescribed in detail.

[0038] In some embodiments, additional classes of devices which the NSDwill protect are defined, with different security policies defined foreach class of devices. For example, internal devices which are in directcommunication with external devices (e.g., HTTP and FTP servers) may bespecified in an optional class. Optional devices are typically affordedsome level of trust greater than external devices but less than trusteddevices, such as by monitoring some communications between optional andtrusted devices. Thus, security policy templates and specific securitypolicies can be viewed as defining levels of trust given to variousspecific devices or classes of devices.

[0039] Each NSD has a supervisor device which is designated as theprimary supervisor device for that NSD. For example, supervisor device120 is the primary supervisor for NSDs 130 through 140, and those NSDsstore information about supervisor device 120 (e.g., the device'snetwork address) with their respective specific security policyinformation 133 and 143 on storage devices 131 and 141. In a similarmanner, supervisor device 160 is the primary supervisor for NSDs 161through 162. NSDs 130 and 140 also store any required access information(e.g., one or more unique passwords which supervisor device 120 mustprovide in order to gain access to the NSDs) along with their respectivedevice access information 134 and 144. The NSD-specific accessinformation and primary supervisor device information can alsooptionally be stored by the manager device along with its supervisordevice and NSD access information 115 and specific security policyinformation 116 respectively. Those skilled in the art will appreciatethat storage devices 131 and 141 can be implemented in a variety ofways, such as by using local or remote storage, and by using a varietyof storage media (e.g., magnetic disk, flash RAM, etc.).

[0040] The manager device has one or more input/output devices 118 (suchas a display) to enable a user (not shown) to interact with the managerdevice. The manager device also stores a variety of information onstorage device 111, including one or more NSD software updates 112,security policy templates 113, and aggregated network securityinformation 114 from one or more NSDs. The manager device alsooptionally stores supervisor device and NSD access information 115(e.g., passwords and a decryption key for stored information) as well asspecific security policy information 116 (including NSD-specificconfiguration information) for one or more NSDs. Those skilled in theart will appreciate that storage device 111 can be implemented in avariety of ways, such as by using local or remote storage, and by usinga variety of storage media (e.g., magnetic disk, flash RAM, etc.).

[0041] When a user of the manager device desires to establish or modifya security policy for one or more NSDs such as NSDs 130 and 140, theuser first selects one of the security policy templates 113 or creates anew security policy template. Security policy templates are discussed ingreater detail below with respect to FIG. 3. The manager device thendetermines the one or more primary supervisor devices for the NSDs ofinterest, such as by retrieving this information from its specificsecurity policy information 116. If this information is not stored bythe manager device, the manager device can obtain the information in avariety of ways, such as by querying the NSDs of interest or by queryingthe various known supervisor devices.

[0042] After the one or more primary supervisor devices are known, themanager device sends a single copy of the security policy template toeach of the primary supervisor devices. For example, if the NSDs 130 and140 are selected, a copy of the template is sent to supervisor device120. The primary supervisor devices then send a copy of the securitypolicy template to each of the selected NSDs. Each NSD stores its copyof the security policy template with the NSD's specific securityinformation.

[0043] Each NSD's copy of the security policy template can then beconfigured with information specific to the NSD. For example,information about specific devices of interest from internal network 135will be retrieved, and will be used to configure the security policytemplate for NSD 130. This NSD-specific information will be used toconfigure the security policy template into a specific security policyfor the NSD, and the information will be stored with the specificsecurity policy information for the NSD. The NSD-specific configurationcan be conducted by a user via the manager device, by a local user suchas a system administrator for the NSD, or automatically via adevice-identifying service such as DNS.

[0044] When a user of the manager device desires to initially load ormodify the software to be executed by one or more NSDs such as NSDs 130and 140, the user first selects the software of interest, such as fromNSD software updates information 112. The user can update some or all ofthe software components used by the NSDs. The manager device thendistributes the software components to the NSDs in the same manner asfor the security policy templates, including configuring the copies ofthe software with NSD-specific information if necessary. Each NSD storesthe software, such as NSDs 130 and 140 storing their software with theirsecurity device software 132 and 142 respectively. The NSDs willimplement the defined specific security policy by executing the softwareand using the stored specific security policy information. Those skilledin the art will appreciate that other types of information other thansecurity policy templates and software can be distributed from themanager device to the NSDs in a similar manner.

[0045] As the NSDs execute their specific security policies, they gathervarious network security information of interest. Each NSD forwards itsnetwork security information to its primary supervisor device forstorage. The network security information can be forwarded to thesupervisor device in a variety of ways, such as immediately upongeneration, on a periodic basis, or when the supervisor device requeststhe information. For example, NSDs 130 and 140 forward their networksecurity information to supervisor device 120 for storage in thesupervisor device's network security information log 125. If supervisordevice 120 becomes unavailable, NSDs 130 and 140 will forward theirnetwork security information to another supervisor device, such assupervisor device 160. Supervisor device 160 stores the network securityinformation it receives in network security information log 165. Thus,each supervisor device maintains one or more logs containing networksecurity information sent by NSDs associated with the supervisor device.

[0046] When a user of the manager device desires to see the networksecurity information of an NSD such as NSD 120, the manager deviceretrieves the network security information from each supervisor devicewhich stores any of the network security information (e.g., any securityinformation generated between two specified times, or all securityinformation that is available). The manager device can determine theseone or more supervisor devices in a variety of ways. For example, eachof the supervisor devices can periodically inform the manager device ofthe NSDs which are currently associated with the supervisor device, andthe manager device can store this information with its specific securitypolicy information 116. The manager device can then aggregate thenetwork security information that is retrieved from multiple supervisordevices in a variety of ways, such as chronologically, by event type,etc. This aggregated network security information can be stored by themanager device in the aggregated network security information 114 of themanager device, either individually or with the security information ofother NSDs.

[0047] Those skilled in the art will appreciate that each device of theNSDM system may be composed of various components such as a CPU, memory,input/output devices (e.g., a display and a keyboard), and storage(e.g., a hard disk or non-volatile flash RAM). In addition, thoseskilled in the art will appreciate that the described embodiment of theNSDM system is merely illustrative and is not intended to limit thescope of the present invention. The system may contain additionalcomponents or may lack some illustrated components. In particular, theremay be multiple manager devices and/or multiple hierarchical layers ofsupervisor devices such that some supervisor devices supervise othersupervisor devices. Alternately, the manager device and one or moresupervisor devices may be implemented as a single computer system suchthat the manager device communicates directly with NSDs. Also, in someembodiments the devices which host network security information for theNSDs can be separate devices from those which supervise and sendmanagement information to the NSDs. Accordingly, the present inventionmay be practiced with other configurations.

[0048] Referring now to FIG. 2, an embodiment of the NSDM system is usedto illustrate how network security information from an NSD is stored bymultiple supervisor devices. In some embodiments, each NSD has not onlya primary supervisor device which is associated with the NSD, but alsoone or more additional associated supervisor devices (e.g., secondaryand tertiary devices, or multiple secondary devices). As with theprimary supervisor device, these additional supervisor devices for anNSD can be specified in a variety of ways, such as by a user of themanager device during configuration of the NSD or automatically based ona variety of criteria (e.g., geographic proximity to the NSD, capacityof the supervisor device, etc.). Each NSD can store information aboutthe additional supervisor devices with their specific security policyinformation, as well as any required access information for theadditional supervisor devices along with their device accessinformation.

[0049] As is discussed above with respect to FIG. 1, supervisor device120 has been designated as the primary supervisor device for NSD 130. Asis illustrated in FIG. 2, two other supervisor devices have also beenassociated with NSD 130. In particular, supervisor device 160 has beendesignated as a secondary supervisor device for NSD 130, and supervisordevice 210 has been designated as a tertiary supervisor device. Thoseskilled in the art will appreciate that any number of supervisor devicescould be associated with any given NSD, and that different NSDs can havedifferent groups of associated supervisor devices. Supervisor devices160 and 210 maintain network security information logs 165 and 215respectively, and supervisor devices 120, 160 and 210 are all able tocommunicate with security policy manager device 110.

[0050] As is illustrated, NSD 130 protects multiple trusted devices 220through 230 in internal network 135 from external devices in externalnetwork 190 (not shown). As NSD 130 implements its specific securitypolicy and notes events of interest, it gathers various network securityinformation related to the events. When NSD 130 has network securityinformation that is to be transmitted to a supervisor device forstorage, NSD 130 first determines if primary supervisor device 120 isavailable to host the information (e.g., by sending a status querymessage to the device). If primary supervisor device 120 is able toreceive network security information from NSD 130 and has the capacityto store the information, NSD 130 sends the network security informationto supervisor device 120 for storage in the network security informationlog 125.

[0051] If, however, primary supervisor device 120 is not available tohost the network security information from NSD 130, the NSD determinesan alternate host supervisor device (referred to as a “fail-over”).Since supervisor device 160 has been designated as the only secondarysupervisor device, NSD 130 determines if that supervisor device isavailable to host the network security information. If so, supervisordevice 160 becomes the supervisor device currently associated with NSD130, and the NSD forwards the information to the supervisor device. Ifsupervisor device 160 is not available, the NSD determines a nextsupervisor device (e.g., supervisor device 210) to check foravailability. In this manner, the network security information for asingle NSD may be stored across multiple host supervisor devices. Asdiscussed above, the manager device can be informed as to the NSDscurrently associated with each supervisor device in a variety of ways,such as by the supervisor devices or the NSDs periodically sendingstatus messages to the manager device.

[0052] The details of how the fail-over process works can be implementedin a variety of ways. For example, in some embodiments after NSD 130 hasswitched its current association to an alternate supervisor device suchas supervisor device 160, NSD 130 will continue to use that supervisordevice as its host device until that supervisor device becomesunavailable. Alternately, the NSD could instead continue to try to sendnetwork security information to its primary supervisor device even ifthe current supervisor device remains available, such as by periodicallychecking the availability of the primary supervisor device or by firstattempting to send each portion of network security information to theprimary supervisor device. In addition, if an alternate supervisordevice such as supervisor device 160 becomes unavailable, NSD 130 couldfirst check the primary supervisor device for availability beforechecking other alternate supervisor devices, or could instead check thenext supervisor device (supervisor device 210) that is associated withthe NSD.

[0053] Those skilled in the art will also appreciate that fail-overamong multiple supervisor devices can occur in a variety of ways. Forexample, additional supervisor devices can be associated with an NSDonly when needed, such as when the primary supervisor device becomesunavailable. In addition, the NSDs may use a currently associated hostsupervisor device for reasons other than storing network securityinformation, such as for forwarding messages to the manager device or toother NSDs.

[0054]FIGS. 3A-3H are examples of security policy templates. FIG. 3A isa conceptual diagram illustrating the generation from a single securitypolicy template of specific security policies for each of several NSDsand their respective internal networks. A security template 300 is firstgenerated, such as by a user of the manager device. Then, for each of anumber of different networks 315, 325, 335, etc., the user generates anetwork profile containing NSD-specific information for implementationby the NSD protecting that network. These network profiles are shown asnetwork profiles 310, 320, 330, etc. In order to generate the specificsecurity policy for each network, the security policy template iscombined with the network profile for that network. For example, inorder to create security policy 315 for network 1, the security policytemplate 300 is combined with network profile 310 for network 1.

[0055]FIG. 3B is a conceptual diagram illustrating the creation of asecurity policy in greater detail. In particular, FIG. 3B shows thecreation of security policy 315 for network 1 shown in FIG. 3A. FIG. 3Bshows that the security policy template 300 contains a number ofsecurity policy filter rules, including security policy rule 301.Security policy rule 301 specifies that outgoing FTP connections areallowed only from network elements defined as being within the“InformationServices” alias. While only one security policy rule isshown in security policy template 300 to simplify this example, securitypolicy templates often have a larger number of such security policyrules.

[0056] The network profile 310 for network 1 contains a definition ofthe “InformationServices” alias 311. It can be seen that this definitiondefines the “InformationServices” alias to include the network elementsat the following IP addresses:

[0057] 220.15.23.52

[0058] 220.15.23.53

[0059] 220.15.23.97

[0060] In general, a network profile contains an alias definition likealias definition 311 for each alias used in the security policytemplate.

[0061] When the security policy template 300 and the network profile 310for network 1 are combined to create the security policy 315 for network1, the facility replaces the “InformationServices” alias in rule 301with the network addresses listed for the “InformationServices” alias indefinition 311. Doing so produces rule 316 in the security policy 315for network 1, which indicates that outgoing FTP connections are allowedonly from the network elements having IP addresses 220.15.23.52,220.15.23.53, and 220.15.23.97. In the same manner, for each additionalrule in security policy template 300, each occurrence of an alias isreplaced with the network addresses of the network elements defined tobe within the alias in the network profile 310 for network 1. As aresult, the rules in security policy 315 for network 1, which are to beimplemented in network 1, specifically refer to network elements withinnetwork 1. In this sense, they differ from the rules in securitypolicies 325 and 335, which specifically refer to network elementswithin networks 2 and 3, respectively.

[0062]FIGS. 3C-3H provide exemplary graphical user interface screenssuch as may be provided by a manager device to assist in definingsecurity policy templates. Referring now to FIG. 3C, a variety ofaliases are available to be used in creating security policy templates.Note that aliases may be related to services and protocols (e.g., H323and FTP) as well as to conceptual identifications of one or more networkdevices such as may be based on a particular NSD customer's network(e.g., Accounting, Marketing, Production, Sales, and TopMgmt). As isillustrated, filter rules have been defined for the H323 and FTPaliases. Referring now to FIG. 3D, a specific filter rule such as for aparticular service is illustrated in detail, allowing control forincoming and outgoing packets based on specific senders and recipients.Each filter rule can include associated information as to whether togenerate network security information when the rule applies (e.g., viathe Logging button). Referring now to FIG. 3E, an interface for definingaliases is shown along with a list of various defined exemplary aliases.

[0063] Referring now to FIG. 3F, an example of a user interface forconfiguring a security policy template for a specific NSD of aparticular customer is shown. In particular, a filter rule for theavailable service ping is shown. In the illustrated embodiment, aWatchGuard service has also been defined to manage communicationsbetween the NSD and supervisor devices. Configuring the NSD can includespecifying Contact Information for the customer (e.g., company name,contact person, customer ID, etc.), Identification and Accessinformation (e.g., the NSD name and serial number, the NSD external IPaddress, a modem number that is used by the NSD, etc.), NetworkConfiguration information (e.g., IP addresses for the default gatewayand for the trusted, external and optional interfaces, as well as hostsand networks related to each of the interfaces), Out Of Band (OOB)information to specify how to communicate with the NSD in ways otherthan through the external network (e.g., via a modem or serial port),Route information (e.g., network routing information when the customeruses a router to connect one or more secondary networks to a networkbehind the NSD), Authentication information to specify how user and/ordevice authentication will be performed, Log Host information about theone or more supervisor devices associated with the NSD (e.g., a list ofsupervisor devices in order of precedence, with the primary supervisordevice first, as well as password and other access information needed tointeract with the devices), and Miscellaneous information such as thecurrent time zone.

[0064]FIGS. 3G and 3H provide exemplary information related to events ofinterest and the specifying of network security information of interest.Referring first to FIG. 3H, various configuration information for anHTTP proxy service is shown, including types of information which may bedenied passage (e.g., submissions, JAVA™ or ACTIVEX™ applets, andvarious types of information such as audio, images, text, and video) aswell as whether to log network security information about accesses ofthe service. Referring now to FIG. 3G, a GUI is shown for specifying howto generate network security information, such as for a filter rule orservice, and how to notify indicated users or devices of the networksecurity information.

[0065] Those skilled in the art will appreciate that this information isprovided for exemplary purposes only, and that the invention is notlimited to the specific details discussed.

[0066]FIGS. 4A-4H provide an example of various network securityinformation and NSD status information generated by implementing aspecific security policy. Those skilled in the art will appreciate thatnetwork security information can include a variety of types ofinformation about packets of interest, such as the direction, networkinterface, total length, protocol, header length, time to live, sourceIP address, destination IP address, source port, destination port, ICMPtype and code, information about IP fragmentation, TCP flag bits, and IPoptions. The network security information can also include informationabout the logging itself, such as a time stamp, the action taken afterapplying filter rules, and information about the supervisor/host devicesuch as the device name, corresponding process name, and correspondingprocess ID.

[0067] Those skilled in the art will also appreciate that thisinformation is provided for exemplary purposes only, and that theinvention is not limited to the specific details discussed.

[0068]FIGS. 5A-5D provide examples of a GUI displaying to a user of amanager device a hierarchical view of multiple supervisor devices andNSDs as well as corresponding configuration and network information.

[0069] Referring now to FIG. 5A, a manager device (“Network OperationsCenter”), two supervisor devices (“WEP_1” and “WEP_2”), and seven NSDs(“Computer_Enterprises,” “Bilington_Insurance,” “General_Automotive,”“Fields_Bank,” “Starr_Manufacturing,” “Vision_Cable,” and“Gray_Design_Group”) are illustrated in the upper left pane of the GUI.The first three NSDs are currently associated with the WEP_1 supervisordevice, and the next four NSDs are currently associated with the WEP_2supervisor device. The hierarchical arrangement allows devices to beaccessed in a variety of ways, such as by selecting all of the securitydevices associated with a supervisor device by merely selecting orindicating the supervisor device. Note that supervisor devices and theirassociated security devices can be organized in a variety of ways, suchas by geographical proximity or by conceptual similarity (e.g., groupingcustomers based on similar types of business).

[0070] As is illustrated by the icons shown beside the devices in theleft pane, a variety of information about the devices can be displayedgraphically (e.g., type of device and connection status). In addition,as is shown in the right pane of the GUI, various information about thesupervisor devices and NSDs can be displayed textually (e.g., the IPaddress, connection status, and phone number). The current contents ofthe right pane indicate that a variety of specific information can bedisplayed for a particular security device (in this example,“Computer_Enterprises”). Similarly, other information accessible to thedevice executing the GUI can be displayed, such as the availablesecurity policy templates shown in the lower left pane.

[0071] In addition to the currently displayed information, other toolsand information can also be accessed via the GUI (e.g., via thetop-level menus, pop-up menus for particular displayed items, via thetoolbar, etc.). For example, other available tools include the SecurityManagement System (SMS) tool provides a GUI for viewing and modifyingthe existing security policy, as well as access to higher-levelfunctions such as adjusting proxy settings, customizing web surfingrules and configuring a VPN. The SMS tool allows a user to specifyaccess information for an NSD, examine or edit the configurationinformation of an NSD, save NSD configuration information either locallyor on an NSD, add and delete services for the NSD, specifynetwork-specific addresses for the NSD, set up logging and notificationdetails about network security information, define default packethandling rules, block network information passing to or from certain IPaddresses and port numbers, set up IP masquerading so that the NSDpresents its IP address to the external network in lieu of any specificinternal network addresses, set up port forwarding so that the NSDredirects incoming packets to a specific masqueraded device in theinternal network based on the destination port numbers of the packets,determine the level of security for incoming and outgoing sessions usingproxy services, and organize the internal network by defining aliases,defining groups of internal devices, and defining groups of users (e.g.,with different levels of access privileges).

[0072] Other tools also include the Status Viewer for retrievingspecific status information about an NSD (e.g., version information,uptime, memory usage, active connections, etc.), the Log Viewer fordisplaying network security information, the Host Watch for providing agraphical view of real-time connections between an NSD's trusted andexternal networks, the Service Watch for graphing the number ofconnections of service, the Mazameter for displaying real-time bandwidthusage for a particular NSD interface, and the Historical Reporting torun NSD reports related to exceptions (such as denied packets), usage bysupervisor device, service, or session, time series reports,masquerading information reports, and URL reports.

[0073]FIG. 5B provides an example of a GUI for a Host Watch tool thatprovides a graphical view of real-time connections, and FIGS. 5C and 5Dprovide examples of GUIs for a Status Viewer tool. FIG. 5C indicatesvarious users associated with specific IP addresses, and FIG. 5Dincludes information about IP addresses and ports which are currentlyblocked.

[0074] Those skilled in the art will also appreciate that thisinformation is provided for exemplary purposes only, and that theinvention is not limited to the specific details discussed.

[0075]FIG. 6 is an example of one or more NSD software components whichcan be distributed by a manager device to an NSD. In the illustratedembodiment, the NSD is a security appliance device capable of executingthe Linux operating system. In addition to implementing a specificsecurity policy that generates network security information, the NSD canalso perform additional tasks, such as providing support for VirtualPrivate Networks (VPNs). The NSD software components include a versionof the Linux OS kernel 610 which is capable of executing on the NSD toprovide various OS functionality (e.g., TCP/IP support, network drivers,etc.). The OS software component can also include an applicationprogramming interface (API) so that various other software componentscan interact with the OS kernel in a consistent manner.

[0076] One software component which interacts directly with the OS isthe packet filter engine 615. The packet filter engine implements thespecific security policy for the NSD, and interacts with various othersoftware components including the firewall 630, proxies for variousnetwork services 635, and authentication software 640. The firewallcomponent can provide a variety of functions such as configuringsecurity policy filter rules, providing an interface to implementcommunication and access security (e.g., via encryption), launchingproxies for various network services, and communicating with managementsoftware of the NSD client (e.g., a business which owns the trusteddevices protected by the NSD). The firewall component can provide aclient API 645 which client computers can contact, or can insteadcommunicate with such an API provided by the client. The various networkservice proxies can provide a variety of information about theactivities and configuration of the proxies, and the authenticationsoftware can ensure that users or devices provide the necessary accessinformation before gaining access to the NSD or being able to receiveinformation (e.g., network security information) from the NSD.

[0077] Other software components which interact directly with the OSinclude various functionality-specific drivers (e.g., VPN drivers) 620,and various service and protocol drivers (e.g., TCP/IP driver) 625. Mostfunctionality-specific drivers will also have a corresponding softwarecomponent which implements the functionality and which interacts withthe driver, such as the VPN software 650 interacting with driver 620.Similarly, one or more software components may be associated with theservice and protocol drivers to implement or provide support for thoseprotocols and services, such as the initialization program 655interacting with drivers 625.

[0078] It is also possible for some software components to execute onthe NSD in a manner such that they do not directly interact with othersoftware components. For example, the network security informationlogging component 660 provides network security information tosupervisor devices. While the logging component could interact withother components such as the packet filter engine to retrieve thenetwork security information of interest, the logging component couldalso retrieve the information from a temporary local storage withoutsuch direct interaction. The logging component can provide a supervisordevice API 670 which supervisor devices can contact, or can insteadcommunicate with such an API provided by the supervisor devices. As withthe firewall component and other components providing information oraccess to external devices, the logging component can provide for thesecurity of the information it provides in a variety of ways (e.g.,encrypting the information before transmitting it).

[0079] Finally, as illustrated by the software components 670, a varietyof other optional software components can be provided to and executed byan NSD. These components may or may not interact with other displayedsoftware components. Those skilled in the art will appreciate thatvarious of the displayed software components may interact with eachother even if such interaction is not graphically illustrated, thatexisting software components could be removed, and that various softwarecomponents could alternately be grouped together into a single componentor separated into separate sub-components. In addition, those skilled inthe art will appreciate that various specific types of software (e.g.,the Linux OS and the TCP/IP protocol) could be replaced with alternatetypes of software providing similar functionality.

[0080] Those skilled in the art will also appreciate that thisinformation is provided for exemplary purposes only, and that theinvention is not limited to the specific details discussed.

[0081]FIG. 7 is an exemplary flow diagram of an embodiment of theNetwork Security Device routine 700. The routine implements a specificsecurity policy for an NSD by monitoring network information passingbetween devices of interest (e.g., between external devices and trusteddevices), applying security policy filter rules when appropriate, andgenerating network security information about events of interest. Inaddition, the routine responds to management-related messages (e.g.,from supervisor devices) when appropriate.

[0082] The routine begins at step 705 where the NSD executes an initialboot program that loads the software to be executed by the NSD. Afterthe software is loaded, the routine continues to step 710 to loadvarious NSD-specific network packet filter rules that will be used toimplement the specific security policy for the NSD, as well as any otherNSD-specific configuration information. The software and NSD-specificconfiguration information will typically be stored in non-volatilememory (e.g., flash RAM or a magnetic disk) by the NSD, but can also beloaded from a remote device.

[0083] After step 710, the routine continues to step 715 to monitor anypassing network information. When network information packets ofinterest are detected, the routine continues to step 720 to filter thenetwork information packets by executing the Filter Network Packetssubroutine 720. After filtering the network information packets, theroutine continues to step 725 to generate network security informationabout any events of interest by executing the Generate Network SecurityInformation subroutine 725. The routine then continues to step 730 torespond to any management-related messages received (e.g., from asupervisor device) by executing the Respond To Management Messagesubroutine 730. After step 730, the routine continues to step 790 todetermine whether to continue monitoring network information packets. Ifso, the routine returns to step 715, and if not the routine ends at step795.

[0084] Those skilled in the art will appreciate that network informationcan be monitored and altered in a variety of ways. In addition, networkinformation can be specified in a variety of different types of packets,and can take a variety of forms other than packets. In addition, an NSDcan be implemented in a variety of ways, such as by using ageneral-purpose computer executing specialized software or by using aspecial-purpose computer. For example, the Firebox10 and Firebox100products from WatchGuard Technologies, Inc., of Seattle, Wash., can beused to implement some aspects of an NSD.

[0085]FIG. 8 is an exemplary flow diagram of an embodiment of the FilterNetwork Packets subroutine 720. The subroutine determines whethernetwork information packets match one or more security policy filterrules, applies filter rules as appropriate to determine what actions totake for the packets, and then takes the appropriate action. Thesubroutine begins at step 805 where information about the networkinformation packets of interest are received. The subroutine continuesto step 810 to determine if the packets match one or more of the filterrules. If so, the subroutine continues to step 815 to apply one or moreof the filter rules as appropriate to determine an action to be takenfor the packets. For example, if multiple rules apply then only the rulewith the highest precedence may be used, or alternately each matchingrule may be applied in order of increasing or decreasing precedence.

[0086] If it is instead determined in step 810 that none of the filterrules apply, the subroutine continues to step 820 to determine a defaultaction to be taken for the packets. A variety of types of defaultactions can be used, including denying passage of all packets that arenot explicitly approved, blocking spoofing attacks, blocking port spaceprobes, and blocking address space probes. After steps 815 or 820, thesubroutine continues to step 825 to take the determined action on thepackets. In the illustrated embodiments, the possible actions includedenying or allowing the passage of the packet to the intended recipient.After step 825, the subroutine continues to step 895 and returns.

[0087] Those skilled in the art will appreciate that a networkinformation security policy can be implemented in ways other than usingfilter rules. In addition, default filtering rules can be used such thatsome filter rules will apply to any packet. Moreover, a variety ofactions can be taken on packets other than allowing or denying passageof the packets, including modifying the packets to add or removeinformation, or holding the packets until additional processing (e.g.,manual review) can be performed on the packets. In addition, additionalactions may be necessary for the subroutine based on the format of thepackets. For example, determining whether a packet matches a filter rulemay require first stripping various network transmission informationfrom the packet, and this information may need to be added back to thepacket if the determined action for the packet is to allow its passageto its intended recipient.

[0088]FIG. 9 is an exemplary flow diagram of an embodiment of theGenerate Network Security Information subroutine 725. The subroutinedetermines whether an event of interest has occurred (e.g., theapplication of a filter rule of interest or the detection of a packetmatching predefined characteristics of interest such as corresponding toa particular network service), logs network security information aboutthe event if appropriate, and notifies one or more specified entitiesabout the event if appropriate. The subroutine encrypts informationbefore it is transmitted so that it can be transmitted over an externalnetwork without fear of the information of interest being intercepted.The subroutine begins at step 905 where information about the networkinformation packets of interest are received. The subroutine continuesto step 910 to determine if the packets indicate an event of interestfor which network security information is to be logged.

[0089] If it is determined in step 910 that the packets indicate anevent of interest for which network security information is to belogged, the subroutine continues to step 915 to generate the networksecurity information about the event, such as by extracting informationof interest from the packet including the packet sender, intended packetrecipient, packet direction, etc. The subroutine then continues to step920 to determine the supervisor device currently associated with theNSD. The subroutine next determines in step 925 if the currentsupervisor device is available to receive network security informationfrom the NSD. If not, the subroutine continues to step 930 to determinean alternate supervisor device to be the current supervisor device, andthen returns to step 925 to determine if the new supervisor device isavailable. After a supervisor device is found to be available anddesignated as the current supervisor device, the subroutine continues tostep 933 to encrypt the network security information in a manneraccessible by the current supervisor device (e.g., with an asymmetricpublic key for the supervisor device, or with a symmetric key availableto all supervisor devices). The subroutine then continues to step 935 tosend the encrypted network security information to the currentsupervisor device. Any necessary access information (e.g., passwords)can also be included with the sent information.

[0090] After step 935, or if it is instead determined in step 910 thatthe packets do not indicate an event of interest for which networksecurity information is to be logged, the subroutine continues to step940 to determine if the packets are of a type that require immediatenotification of one or more entities (e.g., users, devices, services,etc.). If so, the subroutine continues to step 945 to notify thedesignated entities in the appropriate manner, such as by using apredefined notification means (e.g., email, a pager, voice mail, amessage containing predefined information, etc.). This communication canalso be encrypted as appropriate. After step 945, or if it is insteaddetermined in step 940 that immediate notification of one or moreentities is not required, the subroutine continues to step 995 andreturns.

[0091] Those skilled in the art will appreciate that network securityinformation can be sent to a supervisor device in alternate ways. Forexample, the NSD could store network security information until asufficient amount was available before sending it to a supervisor, couldsend network security information on a periodic basis, could sendnetwork security information only when requested by a supervisor device,or could temporarily store network security information while theprimary supervisor device or all supervisor devices are unavailable. Inaddition, network security information can be generated in a variety ofways and can include a variety of information, including sending theentire packets of interest, sending only some information from eachpacket, or sending only summary reports about multiple packets. Inaddition, events of interest which trigger the logging of networksecurity information or the notification of some entity can be definedand identified in a variety of ways, such as any packets to or from aparticular device or a device in a particular class of devices, anypackets for which a specific action are taken (e.g., deny passage), anypackets containing contents of interest (e.g., particular words or anattached file of a particular type), any packets corresponding to aparticular type of network service (e.g., HTTP requests), etc. Finally,a variety of means for providing security to information beingtransmitted over a non-secure network can be utilized, includingsymmetric keys, asymmetric keys, passwords, etc.).

[0092]FIG. 10 is an exemplary flow diagram of an embodiment of theRespond To Management Messages subroutine 730. The subroutine determineswhether the NSD has received a management-related message, determineswhether the sender of the message is authorized to access managementfunctions of the NSD, decrypts the message if necessary, and responds tothe message when appropriate. The subroutine begins at step 1005 whereinformation about the network information packets of interest arereceived. The subroutine continues to step 1010 to determine whether thepackets contain a message that is directed to the NSD. If so, thesubroutine continues to step 1015 to determine what access information(e.g., passwords, the sender being on a list of authorized devices,etc.) is required for the message, as well as any information needed todecrypt the message if it is encrypted (e.g., a password, or a public orprivate key). The subroutine continues to step sz17 to decrypt themessage if it is encrypted. The subroutine then continues to step 1020to verify whether the sender of the message has supplied any necessaryaccess information and otherwise met any other access criteria.

[0093] If the necessary access has been verified, the subroutinecontinues to step 1025 to determine if the message is a request forinformation (e.g., status of the NSD, NSD configuration information, ornetwork security information), information being supplied (e.g., asecurity policy template, NSD-specific configuration information, or NSDsoftware), or some other instruction (e.g., reboot the NSD so that newsoftware is used). If it is determined in step 1025 that the message isa request for information, the subroutine continues to step 1030 tosupply the requested information if possible, including encrypting theinformation before sending if appropriate (e.g., if the intendedrecipient is able to decrypt the information, and the information issensitive or if all communications are encrypted) and including anynecessary access information. If it is determined in step 1025 that themessage is information being supplied, the subroutine continues to step1035 to store the information in the appropriate location. In addition,other actions may be taken automatically if appropriate, such as loadingnew software immediately if possible. If it is determined in step 1025that the message is some other instruction, the subroutine continues tostep 1040 to process the instruction if possible.

[0094] After steps 1030, 1035 or 1040, or if it was determined in step1010 that the packets do not contain a message directed to the NSD or instep 1020 that the necessary access has not been verified, thesubroutine continues to step 1095 and returns. Those skilled in the artwill appreciate that a variety of types of messages can be supplied froma supervisor device, directly from a manager device, from another NSD,or from an internal device. In addition, management-related messages caninclude a variety of types of requests, information, and otherinstructions.

[0095]FIG. 11 is an exemplary flow diagram of an embodiment of theSupervisor Device routine 1100. The routine implements a host device forone or more NSDs by receiving network security information of interestand storing the information until requested by a manager device, as wellas assisting the manager device in distributing various information tothe NSDs which are currently associated with the supervisor device.

[0096] The routine begins at step 1105 where the supervisor deviceexecutes an initial boot program that loads the software to be executedby the supervisor device. Those skilled in the art will appreciate thatthe software can be loaded from local or remote storage. After thesoftware is loaded, the routine continues to step 1110 to wait for amessage. After a message is received, the routine continues to step 1115to decrypt the message if it is encrypted. The decryption can be done ina variety of ways, such as by retrieving decryption information based onthe specific sender of the message or based on the type of sender (e.g.,NSD or manager device). The routine then continues to step 1120 todetermine if the message is from an NSD. If so, the routine processesthe message by executing the Process NSD Message subroutine 1125, and ifnot the routine processes the message by executing the Process ManagerOr Supervisor Device Message subroutine 1130. After steps 1125 or 1130,the routine continues to step 1190 to determine whether to continueprocessing messages. If so, the routine returns to step 1110, and if notthe routine ends at step 1195.

[0097] Those skilled in the art will appreciate that a supervisor/hostdevice can be implemented in a variety of ways, such as by using ageneral-purpose computer executing specialized software or by using aspecial-purpose computer. For example, a general-purpose computerexecuting an operating system (e.g., SOLARIS™ from Sun Microsystems) andexecuting software from WatchGuard Technologies, Inc., of Seattle,Wash., such as the WatchGuard Event Processor software, can be used toimplement such aspects of a supervisor/host device. In addition, thoseskilled in the art will appreciate that each supervisor/host device maybe able to support a large number (e.g., 500) of NSDs.

[0098]FIG. 12 is an exemplary flow diagram of an embodiment of theProcess NSD Message subroutine 1125. The subroutine stores networksecurity information sent by NSDs, notifies the manager device if an NSDnot previously associated with the supervisor device begins sendinginformation, and processes other NSD requests as appropriate. Thesubroutine begins at step 1205 where it receives a decrypted copy of themessage sent from the NSD. The subroutine continues to step 1210 todetermine if the sending NSD is on the list of NSDs that are currentlyassociated with the supervisor device. If not, the subroutine continuesto step 1215 to add the NSD to the current list.

[0099] After step 1215, or if it was instead determined that the sendingNSD is on the list of NSDs that are currently associated with thesupervisor device, the subroutine continues to step 1220 where any NSDsthat are shown on the current list but which are not currentlyassociated with the supervisor device are removed from the current list.Whether a listed NSD is still associated with the supervisor device canbe determined in a variety of ways, such as by removing NSDs from whomno messages have been received for a certain amount of time or byremoving NSDs indicated to be associated with other supervisor devices(e.g., by the NSD, the manager device, or the other supervisor device).The subroutine then continues to step 1225 where, if any NSDs have beenadded or removed, the manager device is notified of the changes in thecurrent list of NSDs. As with other communications, this communicationcan be encrypted if appropriate and any necessary access information canbe included in the message.

[0100] The subroutine then continues to step 1230 to determine if themessage from the NSD is composed of network security information. If so,the subroutine continues to step 1235 to store the information in thelog maintained by the supervisor device. The information in the log isencrypted before it is stored so that any other device able to accessthe log cannot obtain access to the contents of the stored networksecurity information. If it is determined in step 1230 that the messagefrom the NSD is not composed of network security information, thesubroutine instead continues to step 1240 to process the message fromthe NSD as appropriate. For example, the NSD may be using the supervisordevice as an intermediary when sending a message to another device suchas the manager device, another NSD, or another supervisor device. Aftersteps 1235 or 1240, the subroutine continues to step 1295 and returns.

[0101] Those skilled in the art will appreciate that NSD messages can beprocessed in a variety of alternate ways. For example, the list of NSDsmay be purged on a periodic basis rather than when each new NSD messageis received, and the manager device can be updated as to the changes inthe list in a similar manner. In addition, each supervisor device canmaintain a single log in which the network security information ofmultiple NSDs is stored, or can alternately maintain individual logs foreach NSD. Similarly, if the supervisor device's log is not accessible toother devices, the information stored in the log file may not beencrypted, with the supervisor device instead encrypting the informationbefore it is sent.

[0102]FIG. 13 is an exemplary flow diagram of an embodiment of theProcess Manager Or Supervisor Device Message subroutine 1130. Thesubroutine receives a copy of a message from the manager device that isto be distributed to multiple NSDs, and distributes a copy of themessage to each of those NSDs which are currently associated with thesupervisor device. The subroutine also receives requests from themanager device or another supervisor device, such as requests from themanager device for the various (potentially distributed) networksecurity information of an NSD, and responds to the request if possible.

[0103] The subroutine begins at step 1305 where it receives a decryptedcopy of the sent message. The subroutine then continues to step 1310 todetermine if the intended recipients of the message include one or moreNSDs. If so, the subroutine continues to step 1315 to send a copy of themessage to each of the intended recipient NSDs which are on the list ofNSDs currently associated with the supervisor device. As with othercommunications, the messages are sent in an encrypted manner ifappropriate and any necessary access information is added to themessage.

[0104] If it is instead determined in step 1310 that the receivedmessage is not intended for NSDs, the subroutine continues to step 1320to determine if the message is a request from a manager device for thenetwork security information of an NSD. If so, the subroutine continuesto step 1325 to retrieve any portions of the requested information whichare stored by the supervisor device in the log. The subroutine thencontinues to step 1330 to determine if any other supervisor devicesstore at least a portion of the requested information. This can bedetermined in a variety of ways, such as by receiving a list of all suchsupervisor devices from the manager device, by querying other supervisordevices if they store any of the requested information (e.g., afteranalyzing the retrieved information and determining that it is notcomplete), by querying the NSD to determine to which supervisor devicesthe NSD has sent network security information, etc.

[0105] If it is determined in step 1330 that other supervisor devicesstore at least a portion of the requested information, the subroutinecontinues to step 1335 to contact those other supervisor devices andretrieve those portions of the information. The subroutine thencontinues to step 1340 to combine the various portions of networksecurity information together. After step 1340, or if it was determinedin step 1330 that other supervisor devices do not store at least aportion of the requested information, the subroutine sends the retrievednetwork security information to the requester in step 1345. As withother communications, the network security information is encrypted andthe necessary access information is supplied with the information.

[0106] The encryption of the network security information to be sent tothe manager device can be handled in a variety of ways. If the othersupervisor devices from which information is retrieved also encrypt theinformation stored in their logs, the information can be sent to therequesting supervisor device without decrypting the information. If themanager device is able to decrypt the various portions of the networksecurity information encrypted by different supervisor devices (e.g., ifall supervisor devices use the same key for encryption), then therequesting supervisor device can just forward the various encryptedportions of information to the manager device. Alternately, if therequesting supervisor device can decrypt the information from thevarious other supervisor devices, the requesting supervisor device cancombine all of the network security information in a decrypted form andthen encrypt the information before sending it to the manager device.Yet another option is for each of the other supervisor devices toencrypt their network security information before sending it to therequesting supervisor device, with the encryption such that therequesting supervisor device can decrypt it (e.g., by using the publickey of the requesting supervisor device). Those skilled in the art willappreciate that other methods of sending this information are readilyapparent.

[0107] If it was instead determined in step 1320 that the messagereceived by the supervisor device is not a request from a manager devicefor the network security information of an NSD, the subroutine continuesto step 1350 to process the message as appropriate. For example, themessage may be from another supervisor device that is gathering thenetwork security information of an NSD in preparation for forwarding theinformation to the manager device. In this situation, the supervisordevice forwards the requested network security information to the othersupervisor device. After steps 1315, 1345 or 1350, the subroutinecontinues to step 1395 and returns.

[0108] Those skilled in the art will appreciate that requests fornetwork security information may be for amounts of information otherthan all available information, such as information generated during aspecified time period or information of a certain type. In suchsituations, only the information requested can be returned, or insteadall available information can be returned and the requester can extractthe desired information. In addition, when sending information tomultiple NSDs that are currently associated with multiple supervisordevices, the manager device could send a single message to a singlesupervisor device (rather than a single message to each of thosesupervisor devices) and have the single supervisor device distribute themessage as necessary to the other supervisor device, or to other NSDswith which the supervisor device is not currently associated.

[0109]FIGS. 14A and 14B are exemplary flow diagrams of an embodiment ofthe Manager Device routine. The routine executes on the manager device,and receives messages from supervisor devices such as indications of thesupervisor devices currently associated with NSDs that are being managedby the manager device. The manager device also receives a variety ofuser commands related to managing the NSDs and supervisor devices, andprocesses the commands as appropriate.

[0110] The routine begins at step 1405 where a graphical user interface(GUI) is displayed to the user. This display provides a hierarchicaltree view of the various supervisor devices and the NSDs which areassociated with each supervisor device. A variety of other types ofinformation can also be conveyed, such as the status of supervisordevices (e.g., available or unavailable), the status of NSDs, the flowof information that is occurring between devices, etc. The GUI alsoallows the user to easily enter management-related commands, and todisplay information of interest such as the aggregated networkinformation of one or more NSDs. After step 1405, the routine continuesto step 1410 to wait for a user command or for a message.

[0111] After receiving a user command or message, the routine continuesto step 1415 to determine if a user command was received. If not, theroutine continues to step 1420 to determine if the received message isan indication of a current association between an NSD and a supervisordevice, such as after a fail-over when the indicated supervisor devicebecame the current supervisor device for an NSD after the primarysupervisor device for the NSD was unavailable. If it is determined instep 1420 that the received message is an indication of a currentassociation between an NSD and a supervisor device, the routinecontinues to step 1425 to store the association information. If it isdetermined in step 1420 that the received message is not an indicationof a current association between an NSD and a supervisor device, theroutine continues to step 1430 to process the message as appropriate.

[0112] If it was instead determined in step 1415 that a user command wasreceived, the routine continues to step 1435 to determine if the commandis to create or modify a security policy template. If so, the routinecontinues to step 1440 to display a list of possible network servicesand protocols that may be of interest. The routine then continues tostep 1445 where the user can indicate one or more services or protocolsfor which filter rules are to created. For each service or protocol, theuser specifies the specific characteristics which network informationpackets must have to match the rule (e.g., from a specific sender to anyrecipient, or incoming messages from any device of a specified type orclass). The user also specifies the appropriate action to be taken withnetwork information packets that satisfy the rule. The user can alsospecify aliases which are to be customized with NSD-specificconfiguration information when the template is loaded on a particularNSD. For example, if the user defines one or more filter rules relatedto an internal HTTP server, an alias can be created that will eventuallyhold the NSD-specific information about the particular HTTP server.After the filter rules and other information of the security policytemplate are defined or modified, the security policy template isstored.

[0113] If it was instead determined in step 1435 that the command is notto create or modify a security policy template, the routine continues tostep 1450 to determine if the command is to distribute a security policytemplate to one or more NSDs. If so, the routine continues to step 1455to receive an indication from the user of the template to bedistributed, and to then retrieve a copy of the indicated template. Ifit was instead determined in step 1450 that the command is not todistribute a security policy template to one or more NSDs, the routinecontinues to step 1460 to determine if the command is to distribute oneor more software components to one or more NSDs. If so, the routinecontinues to step 1462 to receive an indication from the user of thesoftware components to be distributed, and to then retrieve copies ofthe indicated software components. After steps 1455 or 1462, the routinecontinues to step 1464 to receive from the user an indication of theNSDs to receive either the template or the software components. Theroutine continues to step 1466 to determine the one or more supervisordevices currently associated with the indicated NSDs, and then continuesto step 1468 to send a single copy of the information to be distributedto each of the determined supervisor devices. The copy of theinformation sent to the supervisor devices includes an indication of theNSDs that are to receive the information being distributed.

[0114] If it was instead determined in step 1460 that the command is notto distribute one or more software components, the routine continues tostep 1470 to determine if the command is to configure an NSD bysupplying NSD-specific information to customize a security policytemplate. If so, the routine continues to step 1472 to receive anindication of the NSD to be configured. The routine then continues tostep 1474 to receive an indication from the user of the NSD-specificinformation which is to be used to configure the NSD. The routine thendetermines in step 1476 the supervisor device that is currentlyassociated with the NSD, and in step 1478 sends the NSD-specificinformation to the supervisor device for forwarding to the NSD. Thoseskilled in the art will appreciate that rather than merely sending theinformation to the NSD, the supervisor device could send instructions tothe NSD to load or modify the configuration of the NSD in an appropriatemanner.

[0115] If it was instead determined in step 1470 that the command is notto configure an NSD, the routine continues to step 1480 to determine ifthe command is to retrieve aggregated network security information froman NSD. If so, the routine continues to step 1482 to receive anindication of the NSD. The routine then continues to step 1484 todetermine the supervisor device that is currently associated with theNSD, and in step 1485 determines all supervisor devices which storenetwork security information for the NSD. The routine then continues tostep 1486 to notify the current supervisor device to retrieve thenetwork security information of interest for the NSD, includingindicating to the current supervisor device the other supervisor deviceswhich may store portions of the network security information. Theroutine then continues to step 1487 to wait for the network securityinformation. After receiving the network security information, theroutine in step 1488 aggregates the network security information asappropriate. Those skilled in the art will appreciate that the networksecurity information can be aggregated in a variety of ways, eitherautomatically or in response to user indications.

[0116] If it was instead determined in step 1480 that the command is notto retrieve aggregated network security information, the routinecontinues to step 1490 to process the command if appropriate. Aftersteps 1425, 1430, 1445, 1468, 1478, 1488, or 1490, the routine thencontinues to step 1492 to determine whether to continue processingmessages and commands. If so, the routine returns to step 1410, and ifnot the routine ends at step 1495.

[0117] Those skilled in the art will appreciate that a manager devicecan be implemented in a variety of ways, such as by using ageneral-purpose computer executing specialized software or by using aspecial-purpose computer. For example, a general-purpose computerexecuting an operating system (e.g., WINDOWS 95™ or WINDOWS NT™ fromMicrosoft Corp.) and executing software from WatchGuard Technologies,Inc., of Seattle, Wash., such as the Global Policy Manager, GraphicalMonitor, Historical Reporting Module, Global Console, WebBlocker, BranchOffice VPN, Network Configuration Wizard and Security Management System(SMS) Control Center software components, can be used to implement someaspects of a manager device.

[0118] From the foregoing it will be appreciated that, although specificembodiments of the invention have been described herein for purposes ofillustration, various modifications may be made without deviating fromthe spirit and scope of the invention. Accordingly, the invention is notlimited except as by the appended claims.

1. A method for a security manager device to manage a plurality ofnetwork security devices with a plurality of supervisor devices, eachnetwork security device generating network security information relatedto an associated group of network devices, storing the generated networksecurity information on a primary supervisor device for the networksecurity device when the primary supervisor device is available to storethe generated network security information, and storing the generatednetwork security information on an alternate supervisor device when theprimary supervisor device is unavailable, the method comprising:distributing security control information to multiple network securitydevices, the security control information to be used to generate networksecurity information, by determining a supervisor device that is theprimary supervisor device for each of the multiple network securitydevices; sending a single copy of the security control information tothe determined supervisor device; and indicating to the determinedsupervisor device to send a copy of the security control information toeach of the multiple network security devices; and aggregating thenetwork security information generated by an indicated one of themultiple network security devices using the security controlinformation, by determining at least one alternate supervisor devicethat stores at least a portion of the network security informationgenerated by the indicated network security device; notifying theprimary supervisor device for the indicated network security device of adesire for the generated network security information, the notifyingincluding an indication of the determined alternate supervisor devices;and in response, receiving the generated network security information,so that the manager device can efficiently distribute information tomultiple network security devices, and can retrieve all of the generatednetwork security information for a network security device becausealternate supervisor devices will store the information when the primarysupervisor device for the network security device is unavailable.
 2. Themethod of claim 1 including generating network security information by,for each network security device: monitoring network information passingbetween any network device in the associated group for the networksecurity device and any network device not in the associated group; andwhen the monitored network information is of an indicated type,determining whether the primary supervisor device for the networksecurity device is available to receive information; when the primarysupervisor device is available, sending network security informationabout the monitored network information to the primary supervisor devicefor storage; and when the primary supervisor device is not available,sending network security information about the monitored networkinformation to an alternate supervisor device for storage.
 3. The methodof claim 2 wherein for each network security device, a security policyfor the network security device specifies the indicated types ofmonitored network information for which to generate network securityinformation and specifies data related to the monitored networkinformation to be included in the generated network securityinformation.
 4. The method of claim 1 wherein the distributed securitycontrol information is software to be executed by the multiple networksecurity devices to control the generation of the network securityinformation.
 5. The method of claim 1 wherein the distributed securitycontrol information is a security policy template that defines thenetwork security information to be generated, and including: after acopy of the security policy template has been sent to each of themultiple network security devices, configuring each copy of the securitypolicy template with information specific to the network security deviceto which the security policy template was sent.
 6. The method of claim 1wherein after the notifying of the primary supervisor device, theprimary supervisor device sends the generated network securityinformation to the manager device by: retrieving from each of thedetermined alternate supervisor devices the network security informationgenerated by the indicated network security device; retrieving anynetwork security information generated by the indicated network securitydevice that is stored by the primary supervisor device; and sending theretrieved network security information to the manager device.
 7. Themethod of claim 1 including after the receiving of the generated networksecurity information, aggregating the portions of the generated networksecurity information stored by the determined alternate supervisordevices and any portion of the generated network security informationstored by the primary supervisor device.
 8. The method of claim 1wherein information is sent between the manager device and thesupervisor devices and between the supervisor devices and the networksecurity devices in a secure form so that others do not have access tocontents of the information.
 9. The method of claim 1 includingdisplaying to a user the plurality of network security devices and theplurality of supervisor devices in such a manner that the primarysupervisor device for each of the network security devices is visuallyindicated, and wherein the distributing of the security controlinformation to the multiple network security devices is in response toselection by the user of the displayed multiple network securitydevices.
 10. The method of claim 1 including displaying to a user theplurality of network security devices and the plurality of supervisordevices in such a manner that the primary supervisor device for each ofthe network security devices is visually indicated, and wherein theaggregating of the network security information generated by anindicated one of the multiple network security devices is in response toa visual indication by the user of the one multiple network securitydevice.
 11. A method for collecting security information generated by asecurity device, the generated security information based on networkinformation passing between other network devices, the generatedsecurity information stored on at least one host device distinct fromthe security device, the method comprising: receiving a request for thegenerated security information; determining the host devices on which atleast portions of the generated security information are stored; andwhen there are multiple determined host devices, for each of themultiple determined host devices, retrieving the portions of thegenerated security information that are stored on the host device; andaggregating the retrieved portions of the generated securityinformation.
 12. The method of claim 11 including determining a hostdevice that is a primary host device for the security device, andwherein the portions of the generated security information from each ofthe multiple determined host devices are retrieved from the primary hostdevice after the primary host device collects the portions from themultiple determined host devices.
 13. The method of claim 11 includingrequesting from each of the multiple determined host devices theportions of the generated security information that are stored on thehost device.
 14. The method of claim 11 wherein the aggregating of theretrieved portions of the generated security information includessorting the aggregated security information chronologically.
 15. Themethod of claim 11 wherein the aggregating of the retrieved portions ofthe generated security information includes sorting the aggregatedsecurity information by type of security information.
 16. The method ofclaim 11 wherein the received request for the generated securityinformation is from a user, and including displaying the aggregatedsecurity information to the user.
 17. The method of claim 11 includingdetermining a change needed in network information allowed to passbetween the other network devices based on the aggregated securityinformation.
 18. The method of claim 11 including displaying to a user aview including the security device and the host devices, and wherein therequest for the generated security information involves a visualindication by the user of the security device.
 19. A method forcollecting security information generated by a security device, thegenerated security information based on network information passingbetween other network devices, the generated security information storedon multiple host devices distinct from the security device, the methodcomprising: receiving a request from a manager device for the generatedsecurity information; receiving an indication of the multiple hostdevices which store portions of the generated security information;retrieving from each of the multiple host devices the stored portions ofthe generated security information; and sending to the manager devicethe retrieved portions of the generated security information, so thatthe manager device can aggregate the portions of the generated securityinformation stored by the multiple host devices.
 20. The method of claim19 including: before sending to the manager device the retrievedportions of the generated security information, determining that themanager device is predefined as being authorized to receive thegenerated security information.
 21. The method of claim 19 including:receiving from the manager device access information; and before sendingto the manager device the retrieved portions of the generated securityinformation, determining that the access information authorizes a senderof the access information to receive the generated security information.22. The method of claim 19 including: before sending to the managerdevice the retrieved portions of the generated security information,formatting the retrieved portions in a manner accessible only to themanager device.
 23. The method of claim 19 wherein the indications ofthe multiple host devices which store portions of the generated securityinformation is received from the manager device.
 24. The method of claim19 including before receiving the indications of the multiple hostdevices which store portions of the generated security information,contacting the security device to determine the multiple host devices.25. A method for storing security information generated by a securitydevice in a distributed manner so as to ensure the security informationis available, the security information based on network informationpassing between network devices, the method comprising: identifyingwhether a primary supervisor device for the security device is availableto store received security information; when the primary supervisordevice is available, storing the security information on the primarysupervisor device; and when the primary supervisor device is notavailable, storing the security information on an alternate supervisordevice, so that a manager device can retrieve all of the securityinformation because alternate supervisor devices will store theinformation when the primary supervisor device is unavailable.
 26. Themethod of claim 25 including generating the security information by:retrieving a policy which indicates types of network information;monitoring the network information passing between the network devices;and when the monitored network information is of a type indicated by thepolicy, generating security information about the monitored networkinformation.
 27. The method of claim 26 wherein the policy for thenetwork security device indicates types of information to be included inthe generated security information.
 28. The method of claim 25including: before storing the security information on a supervisordevice, determining that the supervisor device is predefined as beingauthorized to receive the security information.
 29. The method of claim25 including: before storing the security information on a supervisordevice, formatting the security information in a manner accessible onlyto the supervisor device.
 30. The method of claim 25 wherein the methodis performed by the security device, and including sending the securityinformation to the supervisor device that will store the securityinformation in a manner accessible only to the supervisor device.
 31. Amethod for distributing security policy implementation information tomultiple security devices for use in implementing a security policy, themethod comprising: for each of the security devices, determining asupervisor device currently associated with the security device;distributing the security policy implementation information to each ofthe determined supervisor devices; and indicating to each of thedetermined supervisor devices to distribute the security policyimplementation information to the security devices with which thesupervisor device is associated.
 32. The method of claim 31 wherein thesecurity policy implementation information is software to be executed bythe security devices to control the implementing of the security policy.33. The method of claim 31 wherein the security policy implementationinformation is a security policy template that indicates the securityinformation to be generated.
 34. The method of claim 33 including: afterthe security policy implementation information has been distributed toeach of the security devices, configuring the security policyimplementation information distinctly on each security device.
 35. Themethod of claim 31 wherein the security policy implementationinformation is an instruction to be executed by the multiple securitydevices related to the implementing of the security policy.
 36. Themethod of claim 31 wherein the security policy implementationinformation is information common to the multiple security devices, andwherein for each of the multiple security devices the common informationis for configuring a security policy template for the security devicewith information specific to the security device.
 37. The method ofclaim 31 wherein before the security policy implementation informationis distributed to each of the multiple security devices, at least someof the multiple security devices have existing security policyimplementation information of a similar type, and wherein for thosesecurity devices the security policy implementation information to bedistributed will replace the existing security policy implementationinformation.
 38. The method of claim 31 wherein before the securitypolicy implementation information is distributed to each of the multiplesecurity devices, at least some of the multiple security devices haveexisting security policy implementation information of a similar type,and wherein for those security devices the security policyimplementation information to be distributed will supplement theexisting security policy implementation information.
 39. The method ofclaim 31 wherein the distributing of the security policy implementationinformation to each of the determined supervisor devices is performed ina manner such that the security policy implementation information is notaccessible to other devices.
 40. The method of claim 31 includingdisplaying to a user a view of the multiple security devices and thesupervisor devices currently associated with the security devices, andwherein the distributing of the security policy implementationinformation is in response to a visual selection by the user.
 41. Amethod for a supervisor device to distribute security policyimplementation information to multiple security devices for use inimplementing a security policy, the method comprising: receiving from amanager device a single copy of security policy implementationinformation to be distributed to multiple security devices; and for eachof the multiple security devices, if the supervisor device is associatedwith the security device, distributing the security policyimplementation information to the security device.
 42. The method ofclaim 41 wherein the security policy implementation information issoftware to be executed by the security devices to control theimplementing of the security policy.
 43. The method of claim 41 whereinthe security policy implementation information is a security policytemplate that indicates the security information to be generated. 44.The method of claim 43 including: after the security policyimplementation information has been distributed to each of the securitydevices, configuring the security policy implementation informationdistinctly on each security device.
 45. The method of claim 43including: before the security policy implementation information hasbeen distributed to each of the security devices, for each securitydevice configuring distinctly for that device a copy of the securitypolicy implementation information that is to be distributed to thatdevice.
 46. The method of claim 43 including: for each of the securitydevices, sending to the security device a control instruction indicatingan action to be taken with the security policy implementationinformation by the security device.
 47. The method of claim 41 whereinthe security policy implementation information is an instruction to beperformed by the security devices related to the implementing of thesecurity policy.
 48. The method of claim 41 wherein the supervisordevice distributes the security policy implementation information to asecurity device only when the supervisor device is associated with thesecurity device as a primary supervisor device for the security device.49. The method of claim 41 including when the supervisor device is notassociated with one of the multiple security devices, distributing thesecurity policy implementation information to another supervisor deviceto be distributed to the one security device.
 50. A method fordistributing control information to multiple security devices for use incontrolling the operation of the multiple security devices, the methodcomprising: for each of the security devices, determining a supervisordevice currently associated with the security device; distributing thecontrol information to each of the determined supervisor devices; andindicating to each of the determined supervisor devices to distributethe control information to the security devices with which thesupervisor device is associated.
 51. The method of claim 50 whereinafter the control information is distributed to the security devices,the security devices operate in accordance with the control information.52. A method for a security device to operate in accordance withsecurity policy implementation information distributed from a managerdevice, the method comprising: receiving security policy implementationinformation to be used by the security device in implementing a securitypolicy; and using the security policy implementation information toimplement the security policy.
 53. The method of claim 52 wherein thesecurity policy implementation information is distributed to multiplesecurity devices via a supervisor device associated with the multiplesecurity devices.
 54. The method of claim 52 wherein the security policyimplementation information is software to be executed by the securitydevice to control the implementing of the security policy.
 55. Themethod of claim 52 wherein the security policy implementationinformation is a security policy template that indicates securityinformation to be generated.
 56. The method of claim 55 including: afterthe security policy implementation information has been received,receiving from the manager device configuration information specific tothe security device to customize the security policy template.
 57. Themethod of claim 52 wherein the security policy implementationinformation is an instruction to be taken by the security device relatedto the implementing of the security policy.
 58. The method of claim 52including: before using the security policy implementation informationto implement the security policy, determining that the manager device ispredefined as being authorized to distribute the security policyimplementation information.
 59. The method of claim 52 including:receiving from the manager device access information; and before usingthe security policy implementation information to implement the securitypolicy, determining that the access information authorizes a sender ofthe access information to distribute the security policy implementationinformation.
 60. A method for collecting security information generatedby a security device, the generated security information based onnetwork information passing between other network devices, the generatedsecurity information stored on at least one host device distinct fromthe security device, the method comprising: displaying to a user a viewincluding the security device and the host devices; receiving from theuser a visual indication of a security device from which to retrievegenerated security information; determining the host devices on which atleast portions of the generated security information are stored;retrieving the portions of the generated security information that arestored on the determined host devices; and aggregating the retrievedportions of the generated security information.
 61. The method of claim60 including displaying to the user the aggregated generated securityinformation.
 62. The method of claim 60 wherein the view of the securitydevice and of the host devices includes a visual indication of a hostdevice that is a primary host device for the security device.
 63. Themethod of claim 60 wherein the view of the security device and of thehost devices includes visual indications of the determined host devices.64. The method of claim 60 wherein a visual indication displayed in theview of a device performing the method is modified to indicate that thegenerated security information has been retrieved.
 65. A method fordistributing security policy implementation information to multiplesecurity devices for use in implementing a security policy, the methodcomprising: displaying to a user a view of the multiple security devicesand of multiple supervisor devices; receiving from the user visualindications of multiple security devices to which the security policyimplementation information is to be distributed; distributing thesecurity policy implementation information to a supervisor deviceassociated with each of the security devices; and indicating to theassociated supervisor device to distribute the security policyimplementation information to each of the security devices.
 66. Themethod of claim 65 including: displaying to the user multiple pieces ofsecurity policy implementation information; and determining the securitypolicy implementation information to be distributed based on a visualindication by the user.
 67. The method of claim 65 wherein the view ofthe security devices and of the supervisor devices includes a visualindication of a supervisor device that is a primary host device for thesecurity device.
 68. The method of claim 65 wherein a visual indicationfor each of the multiple security devices is modified to indicatereceipt by the security device of the security policy implementationinformation.
 69. A method for displaying security information generatedby a security device, the generated security information based onnetwork information passing between other network devices, portions ofthe generated security information stored on multiple host devicesdistinct from the security device, the method comprising: displaying toa user a view including the security device and the host devices;receiving from the user an indication of a security device from which toretrieve generated security information; and displaying to the user anaggregation of the portions of the generated security informationretrieved from the multiple host devices.
 70. The method of claim 69wherein the view of the security device and of the host devices includesvisual indications of the multiple host devices.
 71. The method of claim69 wherein a visual indication displayed in the view of a deviceperforming the method is modified to indicate that the generatedsecurity information has been retrieved.
 72. A method for distributingsecurity policy implementation information to multiple security devicesfor use in implementing a security policy, the method comprising:displaying to a user a view of a manager device, the multiple securitydevices and of multiple supervisor devices; receiving from the userindications of multiple security devices to which the security policyimplementation information is to be distributed; and displaying to theuser an indication that the security policy implementation informationis distributed to the multiple security devices, the distributionaccomplished by the manager device sending the security policyimplementation information to a supervisor device associated with eachof the security devices and indicating to the associated supervisordevice to distribute the security policy implementation information toeach of the security devices.
 73. The method of claim 72 including:displaying to the user multiple pieces of security policy implementationinformation; and determining the security policy implementationinformation to be distributed based on a visual indication by the user.74. The method of claim 72 wherein the view of the security devices andof the supervisor devices includes a visual indication that theassociated supervisor device distributes the security policyimplementation information to each of the security devices.
 75. Themethod of claim 72 wherein a visual indication for each of the multiplesecurity devices is modified to indicate receipt by the security deviceof the security policy implementation information.
 76. The method ofclaim 72 wherein the multiple security devices to which the securitypolicy implementation information is to be distributed are indicatedfrom a selection by the user of the associated supervisor device.
 77. Acomputer-readable medium whose contents cause a manager device tocollect security information generated by a security device, thegenerated security information based on network information passingbetween other network devices, the generated security information storedon at least one host device distinct from the security device, by:receiving a request for the generated security information; determiningthe host devices on which at least portions of the generated securityinformation are stored; and when there are multiple determined hostdevices, for each of the multiple determined host devices, retrievingthe portions of the generated security information that are stored onthe host device; and aggregating the retrieved portions of the generatedsecurity information.
 78. The computer-readable medium of claim 77wherein the contents further cause the manager device to determine ahost device that is a primary host device for the security device, andwherein the portions of the generated security information for each ofthe multiple determined host devices are retrieved from the primary hostdevice.
 79. The computer-readable medium of claim 77 wherein theaggregating of the retrieved portions of the generated securityinformation includes sorting the aggregated security informationchronologically.
 80. The computer-readable medium of claim 77 whereinthe received request for the generated security information is from auser, and wherein the contents further cause the manager device todisplay the aggregated security information to the user.
 81. Thecomputer-readable medium of claim 77 wherein the contents further causethe manager device to display to a user a view including the securitydevice and the host devices, and wherein the request for the generatedsecurity information involves a visual indication by the user of thesecurity device.
 82. A computer-readable medium whose contents cause amanager device to distribute security policy implementation informationto multiple security devices for use in implementing a security policy,by: for each of the security devices, determining a supervisor devicecurrently associated with the security device; distributing the securitypolicy implementation information to each of the determined supervisordevices; and indicating to each of the determined supervisor devices todistribute the security policy implementation information to thesecurity devices with which the supervisor device is associated.
 83. Thecomputer-readable medium of claim 82 wherein the security policyimplementation information is software to be executed by the securitydevices to control the implementing of the security policy.
 84. Thecomputer-readable medium of claim 82 wherein the security policyimplementation information is a security policy template that indicatesthe security information to be generated.
 85. The computer-readablemedium of claim 84 wherein the contents further cause the manager deviceto, after the security policy implementation information has beendistributed to each of the security devices, configure the securitypolicy implementation information distinctly on each security device.86. The computer-readable medium of claim 82 wherein the security policyimplementation information is an instruction to be executed by themultiple security devices related to the implementing of the securitypolicy.
 87. The computer-readable medium of claim 82 wherein thecontents further cause the manager device to display to a user a view ofthe multiple security devices and the supervisor devices currentlyassociated with the security devices, and wherein the distributing ofthe security policy implementation information is in response to avisual selection by the user.
 88. A computer system for collectingsecurity information generated by a security device, the generatedsecurity information based on network information passing between othernetwork devices, the generated security information stored on at leastone host device distinct from the security device, comprising: a userinterface component that receives from a user a request for thegenerated security information; and a security information retrieverthat determines the host devices on which at least portions of thegenerated security information are stored, and that when there aremultiple determined host devices, for each of the multiple determinedhost devices, retrieves the portions of the generated securityinformation that are stored on the host device and aggregates theretrieved portions of the generated security information.
 89. Thecomputer system of claim 88 wherein the user interface component iscapable of generating a graphical display of the aggregated securityinformation.
 90. The computer system of claim 88 wherein the userinterface component is capable of generating a graphical displayincluding a hierarchical view of the security device and the hostdevices, and wherein the user interface component is further forreceiving a visual indication of the security device indicating therequest for the generated security information of the indicated securitydevice.
 91. A computer system for distributing security policyimplementation information to multiple security devices for use inimplementing a security policy, comprising: a security device associatorfor determining for each of the security devices a supervisor devicecurrently associated with the security device; and an informationdistributor for distributing the security policy implementationinformation to each of the determined supervisor devices, and forindicating to each of the determined supervisor devices to distributethe security policy implementation information to the security deviceswith which the supervisor device is associated.
 92. The computer systemof claim 91 wherein the security policy implementation information issoftware to be executed by the security devices to control theimplementing of the security policy.
 93. The computer system of claim 91wherein the security policy implementation information is a securitypolicy template that indicates the security information to be generated.94. The computer system of claim 91 including a user interface componentfor displaying to a user a view of the multiple security devices and thesupervisor devices currently associated with the security devices, andfor receiving a visual selection by the user that controls thedistributing of the security policy implementation information.
 95. Acomputer system for storing security information generated by a securitydevice in a distributed manner so as to ensure the security informationis available, the security information based on network informationpassing between network devices, comprising: a storage identifier foridentifying whether a primary supervisor device for the security deviceis available to store received security information; and an informationstorer for storing the security information on the primary supervisordevice if the primary supervisor device is available, and for storingthe security information on an alternate supervisor device when theprimary supervisor device is not available.
 96. The computer system ofclaim 95 further comprising: a security information generator forretrieving a policy which indicates types of network information, formonitoring the network information passing between the network devices,and for generating security information about the monitored networkinformation when the monitored network information is of a typeindicated by the policy.
 97. The computer system of claim 95 furthercomprising: a security component for determining that a supervisordevice is predefined as being authorized to receive the securityinformation before storing the security information on the supervisordevice.
 98. A computer system that implements a security policy inaccordance with security policy implementation information distributedfrom a manager device, comprising: a security policy informationreceiver for receiving security policy implementation information to beused in implementing a security policy; and a security policyimplementer for using the security policy implementation information toimplement the security policy.
 99. The computer system of claim 98wherein the security policy implementation information is software to beexecuted by the security device to control the implementing of thesecurity policy.
 100. The computer system of claim 98 wherein thesecurity policy implementation information is a security policy templatethat indicates security information to be generated.
 101. The computersystem of claim 98 further comprising: a security component fordetermining that the manager device is predefined as being authorized todistribute the security policy implementation information before usingthe security policy implementation information to implement the securitypolicy.
 102. A generated data signal transmitted via a data transmissionmedium from a manager device to a supervisor device, the data signalincluding a single copy of security policy implementation information tobe distributed by the supervisor device to multiple security devices,the security policy implementation information for use by the supervisordevices in implementing a security policy, so that the manager devicecan efficiently distribute information to multiple security devices viaa supervisor device.
 103. The data signal of claim 102 wherein thesecurity policy implementation information is software to be executed bythe security devices to control the implementing of the security policy.104. The data signal of claim 102 wherein the security policyimplementation information is a security policy template that indicatesthe security information to be generated.
 105. The data signal of claim102 including configuration information to be distributed by thesupervisor device to at least one security device, the configurationinformation specific to the at least one security device, theconfiguration information for configuring distinctly for the at leastone security device a copy of the security policy implementationinformation that is to be distributed to that device.